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(57) Abstract: A method manages 

configurations of devices in a system that 
communicates information between a device 
and an enterprise. The method includes building 
a defined configuration for a device type. 
The defined configuration includes a set of 
value requirements. An actual configuration 
having values associated with the device is 
compared to the defined configurations. The 
actual configuration and defined configuration 
are stored in a database of the enterprise. 
The method also includes determining, in the 
enterprise, if the values of actual configuration 
match the corresponding value requirements 
of the defined configurations. The method 
runs business logic associated with the device 
based on a result from the step of determining 
if the values of the actual configuration 
match the corresponding values of the defined 
configurations. The matched configurations are 
stored for subsequent use. 
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5 MANAGING CONFIGURATIONS OF DISTRIBUTED DEVICES 

BACKGROUND 

Field of the Art 

The present disclosure generally relates to configuration management databases 
and, more particularly, to systems and methods for managing configurations of 

1 0 distributed devices. 

Background and Relevant Art 

Over time, device manufactures produce many configurations of a given product 
line as features are added and defects are addressed. Manufactures need to know the 
configuration of the devices to be able to support the components and provide the proper 

15 "upgrade" path. The configurations of these devices are changed in the field as 
customers, users, or technicians update hardware and software components. The ability 
to track the configuration of the devices becomes more complex when the device has 
been in the field for a long period of time. For example, the life of a CT scanner or X- 
Ray machine can typically be about 10 to 20 years. 

20 Some devices are regulated by the FDA. When updating hardware or software on 

the regulated devices, the FDA mandates tracking the configuration of certain devices and 
recording software updates. Records are required, for example, on medical devices that 
track these updates. Various methods have been used to track updates, ranging from an 
entire paper system to homegrown systems implemented to track devices in an enterprise 

25 resource planning (ERP) system as part of software bill of materials (BOM). Many 
manufacturers do not trust the data collected in these systems since the data accuracy 
relies on the service technician to properly update the device records, which may or may 
not occur. Sometimes service technicians update devices that were not scheduled to be 
updated, which further compounds the problems. Another complicating factor is that 

30 some end-customers have the ability to apply updates to the device (e.g., when CDs are 
shipped by the manufacturer), which leaves the manufacturer to rely on the customer or 
service technician to report on the status of each update. And on some devices, all control 
is lost by the manufacturer when the end-customers have the ability to update, add, and/or 
remove software. 

35 Databases have been implemented to store relevant information about the devices 

in an organization's information technology (IT) services and to store the relationships 
between those components. This type of database is typically referred to as a 



WO 2008/083177 



-2 - 



PCT/US2007/088858 



5 configuration management database (CMDB). A CMDB generally organizes data 
collected from the components into a way that can be viewed and examined from various 
perspectives. The components of the information system in this context are referred to as 
configuration items (CI). The CI can include software, hardware, documentation, 
personnel, and any other conceivable IT component or combination of components. 

1 0 U. S. Patent Application Publication No. 2005/0193386 to MaCaleb et al. discloses 

a method for remotely updating software in computer systems. In the method, a client 
computer sent information about a software application to a server. The server compared 
the information to the most-updated upgrade package for the software application, which 
is stored in a part database. When the most up-to-date upgrade package was not installed, 

15 the upgrade was automatically sent to the client system. A client database stored 
configuration files for the client systems, which included a list of the installed software 
applications and their versions. MaCaleb discloses a "smart" creation of an update based 
on the "latest version" of components in the parts database. This system does not 
maintain information about the configuration of the device, but uses it to determine the 

20 delta from the latest. This system also does not verify that the update will match the 
configuration of the hardware and software associated with the device. 

In U.S. Patent Application Publication No. 2005/0262076 to Voskuil, a computer 
system is disclosed that is configured for policy-based management of software updates. 
The system maintained group-policy objects, with which groups of computers are 

25 associated. The system obtained identities of software updates from a source and filter 
criteria for each update to determine whether the update should be applied to a particular 
computer. The system assigned newly available updates to selected group-policy objects 
and added the obtained filter criteria to each group-policy object. The system performed 
necessary update installations for each group-policy object by determining whether the 

30 computer satisfied the filter criteria for the update for each combination of a computer 
belonging to a group associated with that policy object and an update assigned to that 
policy object. If so, the system applied the update to that computer. Although this 
system checks whether the update should be applied to a particular computer by applying 
filter criteria, it does not verify the configuration criteria. This system uses group policies 

35 to control software updates. 

The subject matter claimed herein is not limited to embodiments that solve any 
disadvantages or that operate only in environments such as those described above. 
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5 Rather, this background is only provided to illustrate one exemplary technology area 
where some embodiments described herein may be practiced. 

BRIEF SUMMARY OF THE INVENTION 
A method manages configurations of devices in a system that communicates 
information between a device and an enterprise. The method includes building defined 

10 configurations for a device type. The defined configuration includes a set of value 
requirements. An actual configuration of the device is compared to the defined 
configuration. The actual configuration and defined configuration are stored in a 
database of the enterprise. The actual configuration has values associated with the 
device. The method also includes determining, in the enterprise, if the values of actual 

15 configuration match the corresponding values of the defined configuration. The method 
runs business logic associated with the device based on a result from the step of 
determining if the values of the actual configuration match the corresponding values of 
the defined configurations. The matched configurations are stored for subsequent 
evaluation. 

20 In another aspect of the invention, a system manages configurations of a device 

associated with a monitor agent. The system includes a server that communicates with 
the monitor agent. The monitor agent is configured to collect information from the 
device to obtain an actual configuration of the device. A database is configured to store 
the actual configuration of the device and a defined configuration of a device type. The 

25 device type is associated with a set of devices. The defined configuration is built for the 
device type and stored in the database. The defined configuration includes a set of value 
requirements. The actual configuration has values associated with the device. An 
enterprise is configured to compare the actual configuration to the defined configuration 
and to determine whether the values of the actual configuration match the corresponding 

30 values of the defined configuration. The enterprise is configured to store the matching 
defined configuration and running business logic associated with the device based on a 
result from the comparison between the values of the actual configuration and the 
corresponding values of the defined configuration. 

This summary is provided to introduce a selection of concepts in a simplified form 

35 that are further described below in the Detailed Description. This summary is not 
intended to identify key features or essential features of the claimed subject matter, nor is 
it intended to be used as an aid in determining the scope of the claimed subject matter. 
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5 Additional features and advantages will be set forth in the description which 

follows, and in part will be obvious from the description, or may be learned by the 
practice of the teachings herein. Features and advantages of the invention may be 
realized and obtained by means of the instruments and combinations particularly pointed 
out in the appended claims. Features of the present invention will become more fully 
1 0 apparent from the following description and appended claims, or may be learned by the 
practice of the invention as set forth hereinafter. 

BRIEF DESCRIPTION OF THE DRAWINGS 
In order to describe the manner in which the above-recited and other advantages 
and features can be obtained, a more particular description of the subject matter briefly 
15 described above will be rendered by reference to specific embodiments which are 
illustrated in the appended drawings. Understanding that these drawings depict only 
typical embodiments and are not therefore to be considered to be limiting in scope, 
embodiments will be described and explained with additional specificity and detail 
through the use of the accompanying drawings in which: 
20 Figure 1 illustrates a system managing configurations of distributed devices in 

accordance with the various embodiments of the present invention; 

Figure 2 is a flowchart illustrating a method of managing configurations of 
distributed devices in accordance an exemplary embodiment of the invention; and 

Figure 3 is a flowchart illustrating a method of managing configurations of 
25 distributed devices in accordance with another exemplary embodiment of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 
The present system and method includes various embodiments for managing 
configurations of distributed devices. A configuration management database (CMDB) is 
configured to manage configuration items (CI) of devices. The CMDB tracks and 
30 validates the software and hardware used by the device. The system also tracks the 
device configuration, including the state of that configuration and can take an appropriate 
business action. A business action, for instance, can include sending a technician out to a 
site to update the hardware, such as memory, or complete another action, such as sending 
a software update or collecting data. 
35 In one exemplary embodiment of the system, the CMDB updates the devices with 

controlled installations over its lifetime to help assure that the device will operate safely 
after an update installation. Before an update is sent to the device, the CMDB verifies 
that it is compatible with a defined configuration of the device, which is stored in the 
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5 CMDB. If the device is not compatible, a business action can occur before the update is 
sent to the device since the configuration is known. The system can also allow remote 
updates to the software and/or the device configuration. The "latest" configuration of the 
device may not necessarily be the only valid configuration and may require changes to the 
configuration to match a given update. The business logic can take place soon after the 

1 0 comparison or at a later time. The devices, for example, can be regrouped for later action. 
The comparison matches are stored in the enterprise so that it can take future action with 
the devices even if the action takes place days or weeks later. 

An IT department for a large corporation may have many thousands of devices to 
manage on a corporate network, such as server computers, desktop computers, laptops, 

15 firewalls, routers, switches, and the like. IT departments, especially for large 
corporations, may have problems trying to track the configurations of each device. 
Device configurations need to be managed efficiently to be able to handle numerous 
devices. While the device management problem is similar to the IT problem, the 
complexity of managing devices beyond the corporate network or a network not owned 

20 by the service provider and the expected lifetime of the device makes this problem more 
complex. 

The present invention includes many advantages. Device manufactures will be 
able to automatically track and manage device configurations to safely update the devices 
in the field. In addition, the system will streamline device support and service to benefit 

25 businesses, for instance, by reducing costs and improving customer satisfaction. The 
process is streamlined by driving entitlement validation and expediting problem 
diagnosis. Furthermore, the system reduces the time it takes to launch a product in the 
marketplace by improving the time and ability to meet regulatory requirements. 

In one application of the invention, for example, the system can be used to track 

30 medical devices that are regulated by the FDA. Regulated devices often require the 
manufacturer to record device configurations in the event that an important or even 
dangerous defect is found. The FDA regulates tracking and updating methods for 
medical devices to insure quick handling of defects that could cause potential safety 
issues. It is important to know the current device configuration before software or 

35 configuration updates are delivered. The present invention provides a way for the user 
that installs the update to know that the update is compliant with the device and that the 
device will operate safely after the installation. 
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5 A common methodology for dealing with the configuration management problem 

in the IT space is called IT Infrastructure Library (ITIL). The present invention builds on 
the ITIL Configuration Management to deal with the issues raised by device 
manufacturers. 

The system uses Configuration Management. The process identifies and defines 

10 CI in a system, records and reports the status of the CI and Requests for Change, and 
verifies the completeness and correctness of the CI. The CI is a component of an 
infrastructure — or an item, such as a Request for Change, associated with an 
infrastructure — which is or will be under the control of Configuration Management. The 
CI may vary widely in complexity, size, and type, from an entire system, including 

15 hardware, software, and documentation, to a single module or minor hardware 
component. The CMDB contains relevant details of each CI and details of the 
relationships between the CI. 

As shown in FIG. 1, the system can include an enterprise system 100 that 
communicates with at least one device 200 through a local or global computer network 

20 300, such as the Internet, World Wide Web, or other similar network. The enterprise 
system 100 includes a server 110 that is connected to a database 120, such as a CMDB. 
The device 200 communicates with the enterprise 100 at predefined intervals. The 
device, for instance, can include a power meter, MRI machine, printing press, X-Ray 
machine, or other devices that include, or can be adapted to include, a monitor agent. 

25 These devices may vary in complexity and may have a set of subsystems associated with 
them. 

The device 200 contains or is connected through a serial port, USB, network, or 
the like to a monitor agent 220. The monitor agent 220 is configured to monitor the 
device status and verify that the device is properly functioning and maintained. The 

30 monitor agent 220 communicates device information to the enterprise 100 as requested by 
enterprise users or when monitored conditions are met, as defined by rules. The rules can 
include monitoring rules, which are set up by the user in the monitor agent 220 on the 
device side, or dynamic group rules, which are set up by the enterprise user to monitor an 
active status of the devices that belong to the defined group. The status includes 

35 operational status, data readings, or configuration of the device. 

Other devices 400 can be connected to the enterprise system 100 through the 
network 300, such as the global computer network or other local network. The devices 
400 are represented as systems 2 through n to mean any defined amount of devices, which 
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5 can meet, but not exceed, the capacity of the enterprise system 100. As the users' needs 
grow, the enterprise system 100 can be modified to match the users' needs, for example, 
by adding more bandwidth, servers, and/or database capacity. Each of the other devices 
400 includes similar components as those defined in the device 200. 

The monitor agent 220 collects information from the sources of device data, such 

10 as a database, a registry, the file system, or data collection protocols. The type of data 
can include various classes of information including: monitoring data, usage data, and 
configuration data. This data, for example, can include the operational status, operational 
data, usage information, location information, environmental information, SW/HW 
version information (i.e. "configuration" information), or any data available on the device 

15 that can be communicated to the enterprise 100. To collect the data, the monitor agent 
220 uses plug-in modules to collect device information using either standard or device- 
proprietary methods. The monitor agent 220 sends data to the enterprise using Web 
services. The software is not limited to a specific protocol such as simple mail transfer 
protocol (SMTP) or hypertext transfer protocol (HTTP) but may be adapted to any 

20 protocol known by one skilled in the art for data interchange at the hardware device level 
or at application program level. 

The monitor agent 220 can send data sets of information to an enterprise server at 
the time of a triggering event, and just before and after the event, to capture the condition 
of the device to provide a baseline. The data can also be collected at a specific time, such 

25 as every evening or at the close of business. Each time the device is updated or software 
revisions are installed, the data also can be collected. If the user needs information 
outside the prescribed times, a user request can be sent at any time. For instance, if a user 
wants to verify the configuration of the device and does not want to wait for a prescribed 
time, a request can be sent immediately. 

30 The communication between the enterprise 100 and the monitor agent 220 can be 

rejected due to firewalls, NAT, etc. that are implemented to block unwanted 
communication. The system can use a "polling server" model to enhance the ability to 
communication between the device and the enterprise if needed. The "polling server" 
model is discussed, for example, in U.S. Patent Publication No. 2003/0118353 entitled 

35 Method and Apparatus for Managing Intelligent Assets in a Distributed Environment, 
which is hereby incorporated by reference in its entirety. 

When collecting data from a device, the CMDB collects a configuration baseline. 
The baseline is a configuration of a product or system established at a specific point in 
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5 time, which captures both the structure and details of that product or system, and enables 
that product or system to be rebuilt at a later date. The baseline records a snapshot or a 
position of the data. Although the position may be updated later, the baseline remains 
unchanged and available as a reference of the original state and as a comparison against 
the current position of the device. The CMDB collects and stores the actual configuration 
10 of a device. 

The CMDB also stores one or more defined configurations for each device type. 
The defined configuration is a set of elements that describe the value requirements. The 
element can include an attribute and a value. The value may be a literal value, set of 
literal values, or an expression. The expression may contain numerical and Boolean 

1 5 operators and the like. Defined configurations can be nested into a hierarchy to represent 
inherently complex devices. In this case, an element references the set of legitimate 
defined configurations. The collection of elements, including expressions and nested 
defined configurations, are identified as the value requirements of the defined 
configuration. The defined configurations allow the CMDB evaluate to stored device 

20 information that can be used to identify a device configuration, which may in turn be used 
for operations such as verifying whether a software update is compatible with the device. 

Enterprise users create defined configurations based on the devices that the 
manufacturer is building and shipping. The defined configuration is comparable to a 
"specification" for the device. For example, Company X creates a first version of device 

25 Y. During the creation of the product, enterprise users create many constructs describing 
device Y, including a device type, defined configurations, and the like, which enable 
many aspects of remote management. Device Y ships and the enterprise receives actual 
configuration updates for the purchased devices. The enterprise processes those updates 
(e.g., matches defined configurations to the device). Some time later Company X works 

30 on new versions of device Y and creates new defined configurations in the process. Once 
the new device ships, the cycle continues. 

A further component of the defined configuration is the state. The value of the 
state of the device can include, for example, valid, recommended, obsolete, "known bad" 
and other states known by one skilled in the art. The defined configuration has a state or 

35 status that applies to all devices whose actual configuration matches the defined 
configuration. The configuration state of the device is on the defined configuration and 
"inherited" by devices whose actual configuration matches it. If an actual configuration 
does not match any of the defined configurations, then it is generically said to be 
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5 "invalid." The state of the device impacts actions taken when a device's actual 
configuration changes or when the defined configuration status changes. For example, if a 
device's actual configuration changes from obsolete to recommended, no action is 
required. But if a defined configuration status changes from valid to known bad, 
immediate action may be required, including software updates, site visits, or other 

10 prescribed actions. If a defined configuration status changes from valid to obsolete, a less 
aggressive course of action could result, such as a low priority work order to "upgrade the 
device on the next site visit." 

An actual configuration of the device is also stored in the CMDB. The actual 
configuration is collected from each device and can, for example, include hardware 

15 versions, software versions, environmental conditions, operational status, operational 
parameters, and other configuration information that can be collected from the device. 
The actual configurations, like defined configurations, can be simple or complex, for 
example, including values nested in a hierarchy. 

The defined configuration is associated with a device type, such as a laptop, and 

20 the actual configuration is associated a particular device. The actual configuration, which 
is collected from the device, can then be compared to the defined configuration for the 
device type. For example, three devices are compared to a defined configuration of a 
laptop device type below 7 . The defined type in this example is for laptops where the 
defined configuration is shown below in Table A: 
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devicetype = LapTops 


Configuration 


IBM Laptops-T23 


State 


VALID 


Status 


LOCKED 


Mandatory 


Manufacturer 


IBM 


Y 


RAM 


>1GB 


Y 


OS 


Windows XP-Pro 


Y 


HardDisk 




Y 




Seagate-Mi 






WD-32 


Mfg 


Seagate 




Mfg Western Digital 


Model 


29 | 30 | 31 




Model 24 


FWVersion 


1.2.29 






Software 1 




N 




Office 2003 








Word 


2003 






Excel 


2003 






Software 2 




Y 




QuestraSA 








Version 


5.1.236 







Table A 



5 The defined configuration includes various components that can be check against 

the actual configurations of the devices. The defined configuration includes the following 
values: the configuration is IBM Laptops-T23; the state is valid; and the status is locked. 
Other configuration values and types are defined. For example, a configuration type is 
the manufacturer and the value associated with it is IBM. The defined configuration can 

10 also include configuration sets, such as software 1 and software 2 shown above. A 
configuration set can include values that are grouped together based on various 
subsystems. The other configuration types are defined accordingly as shown in Table A. 

Device actual configurations are compared to defined configurations to determine 
which, if any, defined configurations match the device. The meaning of the term match, 

15 as defined within this application, means that a value in the actual configuration of the 
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5 device complies with an expression for an element in the defined configuration, which 
comparison includes, for example, operators such as less than (<), less than or equal to 
(<=), equal to (=), greater than or equal to (>=), and greater than (>), or other Boolean 
operators. The elements of a defined configuration can be tagged as elective or 
mandatory values. If the configuration element is mandatory, then the values of the 

10 actual configuration must match the respective defined value during the comparison 
process. If the configuration element is not mandatory, then the component is not 
required to be present in the system. But if the elective element is present, the 
configurations must match. When the actual configuration does not match any defined 
configuration, then the enterprise can be programmed to find the closest match for the 

15 device, and/or to run business logic to notify the technician or user, or to perform some 
other action. 

Continuing with the example illustrated above, device 1 can include the following 
actual configuration shown below in Table B: 



Device 1 - Actual Configuration 


Manufacturer 


IBM 


RAM 


2GB 


OS 


Windows XP-Pro 


Hard 
Disk 


Mfg 


Seagate 


Model 


30 


FWVersion 


1.2.29 


Softwarel 


Word 


2003 


Excel 


2003 


Software2 


Version 


5.1.236 



Table B 

The actual configuration of device 1 matches the defined configuration in 
20 Table A. The hardware and software comply with the requirements in the defined 
configuration. 

A second device in the example includes the actual configuration shown in 
Table C: 
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Device 2 - Actual Configuration 


Manufacturer 


IrSlvl 


RAM 


ZUD 


OS 


Windows XI -Fro 


Hard 
Disk 


Mfg 


o eagate 


Model 


30 


FWVersion 


1.2.29 


Soft ware 1 


Word 


2000 


Excel 


2000 


Software2 


Version 


5.1.236 



Table C 

5 The software in the second device does not match all the fields in the defined 

configuration because the Word and Excel software applications are 2000, not 2003 as 
defined by the configuration in Table A. Although Word and Excel software are not 
mandatory, if the device includes the software, it must match the defined configuration. 
The mismatch may prompt the system to execute business logic to notify users, to fix, or 
10 to schedule an event to fix the unmatched values. 

In a third device of the example, the actual configuration is shown in Table D 

below: 



Device 3 - Actual Configuration 


Manufacturer 


IBM 


RAM 


512MB 


OS 


Windows XP-Pro 


Hard 
Disk 


Mfg 


Maxtor 


Model 


30 


FWVersion 


1.2.29 


Software2 Version 


5.1.236 



Table D 

There are two values that do not match the defined configuration in the third 
device — the size of the memory and the manufacturer. Since the values do not match and 
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5 these values are mandatory, additional action must be taken to correct the mismatch. For 
example, new hardware can be installed to update the device to match the defined 
configuration. 

The manufacturers can define and store configurations of devices that will ship to 
the field. Over the lifetime of a device, the device manufacturers can also assign or 

1 0 change the state of the device to indicate whether the device or its subsystems have values 
that are valid, recommended, obsolete, known bad, or the like. The defined 
configurations may be simple or complex. A complex configuration can include nested 
configurations or Boolean combinations of attributes and values as discussed above. 

The actual configurations of each device are compared with the defined 

15 configurations to determine matches. If a device does not conform to the defined 
configuration or if the actual device configuration changes, business logic can run to 
provide notification, modify the device type or group, or schedule an action. The 
business logic can include, for example, user notification, external system notification 
(e.g. to schedule a site visit in a CRM system), schedule software updates, or run another 

20 user defined action. 

A method of managing configurations is illustrated in FIG. 2 in accordance with 
the various embodiments of the invention. The method starts in step S20 by building a 
defined configuration for a device type to validate the devices in the field. Step S20 can 
occur immediately before or much earlier than any subsequent step, for example, days, 

25 weeks, months, or even years later. A technician can build the defined configuration 
based on the hardware and software specification for the device. Various elements can be 
added to the defined configuration to match the definition of the device with the 
specification. If a certain component is required, the element can be tagged as 
mandatory. The values in the actual configuration of the device must comply with the 

30 mandatory values of the defined configuration. 

Once the defined configuration is built for the device type, the system may verify 
each device in the device type. Generally, devices configurations are matched when the 
actual configuration is sent from the device to the enterprise to reduce resource 
utilization, such as server load. A user can also request the system to match all devices 

35 based on a previously stored configuration. The events that cause the actual configuration 
to be sent from the device to the enterprise include: agent startup, installation of new 
software through the system, and manual requests from a user of the agent user interface. 
This event can trigger the configuration comparison and matching. In step S21, the actual 



WO 2008/083177 



- 14 - 



PCT/US2007/088858 



5 configuration of the device is compared to the defined configuration. When the actual 
configuration does not match the defined configuration in step S22, the system can run 
business logic for the device in step S23 to notify users about the mismatch or to schedule 
an action to fix the noncompliant software or hardware in the device. The method then 
advances to step S25 to check if the validation process is complete for all the devices in 

1 0 the device type group. 

When the actual configuration matches the defined configuration in step S22, the 
system can run business logic for the device in step S24 such as sending an update to the 
device, associating a state with the device, or grouping the device with other devices. The 
method then advances to step S25. When all the devices have been compared and 

1 5 matched, the process ends for the given device type. 

If the validation process is not complete for all devices in the device type, the 
process continues to step S26 where it advances to the next device. The method then 
repeats the process in step S21 to compare the actual configuration of the next device in 
the device type against the defined configuration. The process continues until the 

20 analysis is complete for the device type or group of devices that are associated with the 
device type. 

Another embodiment of the invention is illustrated in FIG. 3. A method of 
managing configurations starts in step S30 by building a defined configuration for a 
device type to validate the devices in the field. The defined configuration can be built 

25 based on the device hardware and software specification. The defined configuration 
includes various elements that are needed to match the definition of the device with the 
requirements. Some elements can be tagged as mandatory if a component is required. If 
so, the values in the actual configuration of the device must meet or exceed the mandatory 
values of the defined configuration. 

30 In step S31, the actual configuration of the device is compared against the value 

requirements in the defined configuration. The system then determines whether the 
actual configuration matches the defined configuration in step S32. If the values match, 
then in step S33 the system runs business logic associated with the device, such as 
sending a software update or configuration updates. If not, the system can run another set 

35 of business logic for the device as shown in step S34 to notify users about the mismatch 
or to schedule an action to fix the noncompliant software or hardware in the device. After 
step S3 3 or step S34 is complete, the process ends for the device and the data from the 
determined matches are stored in the database. 
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5 The system can be configured to send the software update to the device after it has 

been verified. In another embodiment, the system can be configured to send the update to 
a group of devices that have been verified at one time. After the device is verified, it can 
be placed in a group that corresponds to the updated devices. The groups can be based on 
a group type or set of group types. Device grouping is discussed in more detail below. 

10 Optionally, the devices can be grouped together to simplify actions across 

multiple devices. The devices can be grouped based on certain criteria, such as 
geography, software application, version, extension, device type, model number, 
installation, division, or other device parameter. For example, the verified devices can be 
grouped together and the nonconforming devices can be placed in a separate group. A 

15 device can be added or removed from a given group dynamically without requiring input 
from any user. The movement in and out of groups can occur when an event triggers the 
group evaluation, such as (a) after device registration or profile updates, (b) when 
receiving new device operational, status, environmental data, (c) when receiving new 
configuration information (i.e. new versions), or (d) when alarms and/or alerts are created 

20 for a device. These groups are created automatically and may define where notifications 
are sent and associate other business logic to devices, such as data collection schedules, 
software/patch distribution schedules, and the like. The groups are arranged or created 
such that an administrator is no longer required review each device to verify present 
device conditions. 

25 The system can collect the actual configuration of a device in the same manner as 

described above with respect to grouping. The data, for example, can be collected 
periodically, ad hoc, and on events that are likely to change the configuration, such as 
software and hardware upgrades. When the device information is received, business logic 
can be executed to send notifications or perform another action. 

30 The devices can be associated with defined groups in the system to help organize 

the devices so users can locate the device easily. In addition, "bulk" operations can be 
performed on multiple devices including, for example, software updates or data 
collection, such as data readings, configuration information, file transfers, and the like. 
The groups can also control escalation of alert notifications. Furthermore, they can be 

35 used to control access to devices, for example, which users can view or change 
information regarding certain devices. 

A group hierarchy also can be created if desired. The group hierarchy can include 
dynamically and statically defined groups, where dynamic group hierarchies start at a 
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5 statically defined root group. A dynamically defined group is a group to which devices 
are assigned automatically. To set up a dynamic group, the user defines it by setting up 
criteria against which the devices are evaluated to determine their membership in the 
group. The statically defined group is a group whose device membership has been 
manually defined by an administrator. The administrator creates the group and associates 

1 0 devices with it. When a new device is added to the system, the administrator manually 
associates it with a static group. The dynamic hierarchical groups are created based on 
analysis of dynamic group rules and information collected directly from the device. 

A dynamic group rule can be created to specify how devices will be automatically 
organized into groups when those devices are manually created or provide information to 

15 the enterprise. Devices can be automatically associated with groups based on a set of 
rules or some aspect of their profiles. As devices are added to the system or provide 
updated information to the enterprise, they are automatically associated with the 
applicable dynamic groups. A dynamic group rule causes groups to be created. The first 
time a device is found to match the membership criteria for a dynamic group that group is 

20 created. The static and dynamic groups have a parent group. Those at the top level have a 
special built-in logical parent are called a root. Groups whose parent is the root are called 
root groups. 

Automatic groupings can be created based on device configuration data. For 
example, the group can be defined from the software, firmware, hardware revision 

25 information, as well as other actual configuration information. The groups are matched 
with defined configurations on the enterprise system 100. 

The groups can also be automated based on extended and configurable registration 
information. The information, for example, can include device location, such as country, 
state, city, building, etc., or other customer information, like company name, group, 

30 responsible party, and other identifying information. 

Business rules can also be applied at the device or the enterprise. The device can 
be grouped according to the business rule. For example, devices can be grouped based on 
a dynamic device property exceeding a threshold, such as a temperature, duration, 
pressure, or the like. If the collected information of the device meets a monitoring rule, 

35 then information can be sent to the enterprise where the system evaluates the collected 
information for dynamic group evaluation. The addition and removal of devices to and/or 
from groups manages the group-based business logic. The group-based business logic is 
disassociated from a group when the device is automatically disassociated from the group 
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5 and group based business logic is associated to a new group when the device is 
automatically associated with the new group. For example, when a group has been 
updated, a new group can be created with the updated devices. 

Automatic grouping also can be based on a device condition, such as an alert or an 
alarm. Alarms can be created by the monitor agent or by the enterprise system rules. 
1 0 When an alarm or alert is created, it triggers dynamic group rule evaluation. Alarms and 
alerts are defined by rules or business logic, which will be discussed below. The devices 
that are in a specified alert state, that is, meet a condition defined by a rule, can all be 
grouped together. 

Business logic can also be applied to groups. For instance, if the actual 

15 configuration of a device does not match the defined configuration, then business logic 
can be applied. The business logic is applied to or removed from devices that enter or 
leave a dynamic group, respectively. 

A dynamic group rule can create a hierarchy of groups, not just one flat group. A 
device can belong to multiple groups and subgroups in the hierarchy. The user selects 

20 which static groups to associate with the device or creates a rule specifying the device 
data that should be used to match the current device conditions. During the selection 
process, for instance, the user may choose to group the device by location, device type, 
and software application. The device location may be a high level group, which includes 
many other device types. Thus, the device type group becomes a subgroup of the device 

25 location group. Likewise, different software application groups may be found in the 
device type group making it a subgroup of the device type group. This relationship 
creates a hierarchy of groups and subgroups — the subgroups being defined within another 
group. Some groups may be entirely defined within a group while others may be partially 
defined within the group. The hierarchical groups are defined accordingly for each 

30 device. 

The business logic can send notifications to users about the current or updated 
status of the device. The notifications can be sent to business systems or users, such as 
field service technicians, device operators, etc. assigned to groups that are associated with 
a specific device in an alarm or alert condition. In one embodiment of the present 
35 invention, the notifications are defined as alarms and alerts. The alarm is a notification 
that is recorded and processed when a condition exists. For example, an alarm can be 
triggered when the actual configuration of a device does not match the defined 
configuration. The alarm is tracked and stored in a database. An alert is an action to be 
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5 taken when the alarm condition exists. The alert, for example, can be a user notification 
sent by e-mail or an event notification to another business system, such as a CRM system. 
One alarm can generate multiple alerts, for instance, one alarm can cause an e-mail 
message to be sent to users and a separate notification to other business systems. 

In an alternative embodiment, the notifications can escalate. After a notification 

1 0 has been sent to a group, if it has not been acknowledged within a defined time limit, then 
the notification is escalated to the next higher-level group in the hierarchy. And if the 
notification is not acknowledged on the higher level, then it is escalated to the next group 
and so forth. If the notification is acknowledged within the defined time limit, then it will 
not escalate to the next group. The time limit can be any defined amount of time. 

15 Typically, the time limit is defined in hours. In one example, the time limit may be set 
between three and five hours from the notification. The selection of a time limit is not 
limited to any particular range since it is based on user input. 

The enterprise system 100 can include the various embodiments discussed above. 
The information collected from the devices is managed through the enterprise system 100 

20 to reduce the administrative time it takes to monitor and update each device individually. 
The actual and defined configurations of the devices are stored in the CMDB. The values 
in the actual configuration are checked against the value requirements in the defined 
configuration to determine the configuration of the device. Business logic can be run 
based on the results of the comparison, for example, verifying that the software update 

25 will be compatible with the existing device and subsystems before the update is sent to 
the device. If the values are not compatible, business logic can be executed and a 
technician can update the device to make it compliant with the defined configuration. 
The present invention provides controlled updates to help assure that the devices will 
function properly after the installation is complete. 

30 The present invention may be embodied in other specific forms without departing 

from its spirit or essential characteristics. The described embodiments are to be 
considered in all respects only as illustrative and not restrictive. The scope of the 
invention is, therefore, indicated by the appended claims rather than by the foregoing 
description. All changes which come within the meaning and range of equivalency of the 

35 claims are to be embraced within their scope. 
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5 CLAIMS 
What is claimed is: 

1. In a system that communicates information between a device and an 
enterprise, a method for managing configurations of the devices, the method comprising: 

building a defined configuration for a device type, the defined configuration 
1 0 including a set of value requirements; 

comparing an actual configuration of the device to the defined configuration, the 
actual configuration and defined configuration being stored in a database of the 
enterprise, the actual configuration having values associated with the device; 

determining, in the enterprise, if the values of actual configuration match the 
15 corresponding value requirements of the defined configuration; 

running business logic associated with the device based on a result from the step 
of determining if the values of the actual configuration match the corresponding value 
requirements of the defined configuration; and 

storing the matched configurations for subsequent use. 
20 2. The method of claim 1, further comprising a step of collecting information 

from a device information source to obtain the actual configuration of the device. 

3. The method of claim 1, further comprising a step of establishing at least 
one dynamic group rule based on the result from determining if the values of the actual 
configuration match the corresponding value requirements of the defined configuration. 
25 4. The method of claim 1, further comprising a step of sending a notification 

based on the result from the step of determining if the values of the actual configuration 
match the corresponding value requirements of the defined configuration. 

5. The method of claim 4, wherein the notification is an alert and the step of 
sending the notification further comprises sending the alert to a recipient including at 

30 least one of a user and a business system. 

6. The method of claim 5, further comprising a step of determining the 
recipient of the notification using group associations of a specific device in at least one of 
an alarm and alert condition. 

7. The method of claim 1, wherein the step of building the defined 
35 configuration for the device type further includes setting at least one mandatory element 

in the defined configuration. 

8. The method of claim 7, wherein the mandatory element includes a 
mandatory value requirement and the step of determining if the values of actual 
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5 configuration match the corresponding value requirements of the defined configuration 
further includes requiring a match of the actual configuration to the mandatory value 
requirement of the defined configuration. 

9. The method of claim 7, wherein the step of determining if the values of 
actual configuration match the corresponding value requirements of the defined 

1 0 configuration further includes requiring a match if an elective value requirement of the 
defined configuration is present in the actual configuration. 

10. The method of claim 1, further comprising a step of automatically 
associating the device with a group that reflects the result from the step of determining if 
the values of the actual configuration match the corresponding value requirements of the 

1 5 defined configuration. 

1 1 . The method of claim 1 , wherein the step of determining if the values of 
actual configuration match is repeated for each device in a set of devices. 

12. The method of claim 11, wherein the step of sending an update and the 
step of running business logic are performed after the step of determining if the values of 

20 actual configuration match for all devices in the set of devices. 

13. The method of claim 1, wherein the step of determining if the values of 
actual configuration match the corresponding values of the defined configuration occurs 
after receiving the actual configuration from a device. 

14. The method of claim 1, wherein the step of running business logic includes 
25 sending at least one of a software and configuration update to the device. 

15. The method of claim 1, wherein the step of determining if the values of 
actual configuration match the corresponding value requirements of the defined 
configuration further includes using an expression containing at least one of a Boolean 
operator and numerical comparison operator to make the comparison between the values. 

30 16. The method of claim 1, wherein the step of building a defined 

configuration for a device type further includes building complex defined configurations 
to identify the value requirements. 

17. A system for managing configurations of a device associated with a 
monitor agent, the system comprising: 
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5 a server that communicates with the monitor agent, the monitor agent being 

configured to collect information from the device to obtain an actual configuration of the 
device; 

a database configured to store the actual configuration of the device and a defined 
configuration of a device type, the device type being associated with a set of devices; the 

10 defined configuration being built for the device type and stored in the database, the 
defined configuration including a set of value requirements, and the actual configuration 
having values associated with the device; and 

an enterprise configured to compare the actual configuration to the defined 
configuration and to determine whether the values of the actual configuration match the 

15 corresponding value requirements of the defined configuration, the enterprise being 
configured to store the matching defined configuration and run business logic associated 
with the device based on a result from the comparison between the values of the actual 
configuration and the corresponding values of the defined configuration. 

18. The system of claim 17, wherein the enterprise is configured to collect 
20 information from a device information source to obtain the actual configuration of the 

device. 

19. The system of claim 17, wherein the enterprise is configured to run the 
business logic if a change is determined when the actual configuration of the device is 
compared to the defined configuration. 

25 20. The system of claim 19, wherein the business logic includes sending a 

notification to at least one user including at least one of an alarm and an alert. 

21. The system of claim 20, wherein the alert is sent when the value 
requirements of the defined configuration do not match the actual configuration. 

22. The system of claim 17, wherein the enterprise is configured to 
30 automatically associate the device with a group that reflects the result from the 

comparison between the values of the actual configuration and the corresponding value 
requirements of the defined configuration. 

23. The system of claim 17, wherein the enterprise is configured to repeat the 
comparison between the values in the defined configuration and values of actual 

35 configuration for other devices in the set of devices. 

24. The system of claim 17, further comprising at least one mandatory value 
requirement in the defined configuration, the actual configuration being matched to the 
mandatory value requirement. 
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5 25. The system of claim 17, further comprising an elective value requirement 

in the defined configuration, a match being required if the elective value requirement is 
present in the actual configuration. 



WO 2008/083177 



PCT/US2007/088858 




Figure 1 



WO 2008/083177 



PCT/US2007/088858 



2/3 



Build Defined 
Configuration for a 
Device Type to 
Validate Devices 




S20 



S26 



Advance to 
Next Device 



Compare Actual 
Configuration of Device 
to the Defined 
Configuration 



S21 



S22 



Does Actual 
Configuration Match 
the Defined 
Configuration? 



Yes 



Run Business 
Logic for Device 




No 










S23 


-S24 








Run Business 




Logic for Device 


x 







Figure 2 



WO 2008/083177 



PCT/US2007/088858 



3/3 



Build Defined 
Configuration for a 
Device Type to 
Validate Devices 




S30 



Compare Actual 
Configuration of Device 
to the Defined 
Configuration 



S31 



S32 



Yes 



S33 



Does Actual 
Configuration Match 
the Defined 
Configuration? 



Run Business 
Logic for Device 



No 



S34 



Run Business 
Logic for Device 




Figure 3 



INTERNATIONAL SEARCH REPORT 



International application No. 

PCT/US2007/088858 



A. CLASSIFICATION OF SUBJECT MATTER 

G06F 19/00(2006.01)i 

According to International Patent Classification (IPC) or to both national classification and IPC 

B. FIELDS SEARCHED 

Minimum documentation searched (classification system followed by classification symbols) 
IPC 8 G06F 15/16, 9/46 , H04Q 7/20 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 
Korean Utility models and applications for Utility models since 1975 
Japanese Utility models and applications for Utility models since 1975 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 
eKIPASS(KIPO internal) & keywords : device, management, configuration, OMA, DM 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



US 2005-0055397 Al ( ZHU, Y. et al. ) 10 March 2005 

See figures 3-4, paragraphs [0004] -[0006], [00 19] -[0020], [0027]-[0028] 

US 2006-0236325 Al ( RAO, B. R. et al. ) 19 October 2006 
See abstract, figures 1, 3, paragraphs [0005]- [00 12], claims 1, 22 

US 7,028,081 B2 ( KAWASHIMA, M. ) 11 April 2006 
See abstract, figure 1 



1-25 



1-25 



1, 17 



[ J Further documents are listed in the continuation of Box C. 



See patent family annex. 



* Special categories of cited documents: 

"A" document defining the general state of the art which is not considered 

to be of particular relevance 
"E" earlier application or patent but published on or after the international 

filing date 

"L" document which may throw doubts on priority claim(s) or which is 
cited to establish the publication date of citation or other 
special reason (as specified) 

document referring to an oral disclosure, use, exhibition or other 
means 

document published prior to the international filing date but later 
than the priority date claimed 



"T" 



"X" 



"O" 

iipn 



later document published after the international filing date or priority 
date and not in conflict with the application but cited to understand 
the principle or theory underlying the invention 
document of particular relevance; the claimed invention cannot be 
considered novel or cannot be considered to involve an inventive 
step when the document is taken alone 

document of particular relevance; the claimed invention cannot be 
considered to involve an inventive step when the document is 
combined with one or more other such documents, such combination 
being obvious to a person skilled in the art 
document member of the same patent family 



Date of the actual completion of the international search 
21 MAY 2008 (21.05.2008) 


Date of mailing of the international search report 

21 MAY 2008 (21.05.2008) 


Name and mailing address of the ISA/KR 

JpRHk Korean Intellectual Property Office 

Government Complex-Daejeon, 139 Seonsa-ro, Seo- 
^fk SP S u > Daejeon 302-701, Republic of Korea 

Facsimile No. 82-42-472-7140 


Authorized officer ^-mm**. 
Park Ji Eun 

Telephone No. 82-42-481-8537 X', ' )\\'* r ' 



Form PCT/ISA/210 (second sheet) (April 2007) 



INTERNATIONAL SEARCH REPORT 

Information on patent family members 



International application No. 

PCT/US2007/088858 



Patent document 
cited in search report 



Publication 
date 



Patent family 
member(s) 



Publication 
date 



US 2005-055397 A1 



10.03.2005 



CN 1598851 A 

EP01515571A2 

EP1515571A2 

JP17085281 

JP2005085281A2 

KR 10200500259 13 

KR2005025913A 



23.03.2005 
16.03.2005 
16.03.2005 
31.03.2005 
31.03.2005 
14.03.2005 
14.03.2005 



US 2006-236325 A1 
US 07028081 B2 



19. 10.2006 
11.04.2006 



None 

US20030115314A1 

US2003115314A1 

US2003115314AA 



19.06.2003 
19.06.2003 
19.06.2003 



Form PCT/ISA/210 (patent family annex) (April 2007) 



